Various mechanisms exist for reducing power consumption of a platform. Standard technology for power management is specified in Advanced Configuration and Power Interface (ACPI) version 2.0, which may be found on the public Internet at URL www-acpi-info (note that periods have been replaced with dashes to avoid unintentional hyperlinks in this document). ACPI is the standard most computer systems currently use for power management and is used to describe how the system looks to the operating system. Power management capabilities enable a platform, both at component and system level, to change its operating state to use less power and to resume normal operations. These modes of operation are often called sleep and wake modes. A number of events may trigger a platform to transition to low power state or to transition from a low power state to a more active state. For instance, moving a mouse, pressing a key on the keyboard or receiving a message may cause a platform to transition to an active state from a sleep, or low power, state.
The role of firmware in power management has been typically that the firmware may initiate stand-by or wake events. Often the policy of whether an event should wake or sleep the platform is dictated by the operating system (OS). The firmware will comply with the OS policy.
A typical scenario in existing systems is described herein. The platform is powered up. The firmware initializes the subsystem and eventually loads the OS. While the OS is running, at some point in time, a sleep event is triggered in the platform, perhaps due to time, or inactivity, or user-selection. The OS may trigger a system management interrupt (SMI) to cause a sleep event. The firmware acts upon the SMI and recognizes that the platform is to be put into sleep mode. The firmware initiates sleep mode. The chipset for the platform is programmed to recognize certain actions for triggering wake events. When an event causing a wake event is recognized, the firmware operates once again to wake the platform. The waking of a platform may be similar to boot up, but varies according to ACPI standards. Memory contents should still be intact and the operational context should be maintained. If the processor was in sleep mode, upon waking, the processor resets and re-launches the firmware. The firmware can detect that it is not in boot up mode, because in some sleep modes, memory remains intact. Thus, the firmware executes a process dedicated to waking the platform rather than rebooting it. The firmware will not reinitialize memory, for instance. Once awakened, the firmware transitions control to the operating system.
Some platforms may utilize an extensible firmware interface (EFI) architecture. The Extensible Firmware Interface (EFI) Framework technology, or any implementation of the Extensible Firmware Interface, provides a pre-Operating system (pre-OS) runtime environment. EFI is a specification which defines a new model for the interface between operating systems and platform firmware, commonly known as Basic Input Output System (BIOS). The specification version 1.10, published Dec. 1, 2002, is available on the public Internet at URL developer-intel-com/technology/efi/main_specification.htm. The framework may be found at www-intel-com/technology/framework. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.
The EFI specification is primarily intended for the next generation of Intel® Architecture and Itanium® Architecture-based computers, and is an outgrowth of the “Intel Boot Initiative” (IBI) program that began in 1998. More information about EFI can be found at http://developer.intel.com/technology/efi/.
Legacy BIOS is typically tailored for a specific platform. EFI was developed to allow the operating system (OS) to operate generically and without communicating directly to the platform. EFI is effectively the middle layer between the OS and the platform. The layer beneath the EFI is implemented as BIOS, which is specific to the platform. The layer above EFI exposes the interface with which the OS communicates. When the system boots up and the OS assumes control, the OS is handed the EFI system table by the OS loader. The EFI system table is a data structure with pointers to other tables, or data structures. Some of these data structures contain a set of function pointers. The collections of functions pointed to by these tables are known as the runtime and boot services. Other data structures contain platform information such as the Advanced Configuration and Power Interface (ACPI) tables.
EFI implementations are typically non-interrupt driven environments. A typical OS has interrupt driven Input/Output (I/O). When an I/O device has incoming data, it generates a hardware interrupt. A multi-threaded OS can handle I/O interrupts concurrently with foreground processing. However, EFI utilizes a polled environment. At a pre-defined periodic timer-tick, or scheduling interval, the device drivers poll the I/O devices to see if there is any incoming data, or any data to send. A downside to polling is that the high performance I/O is limited by how often the timer-tick occurs. If the timer-tick is not often enough, incoming data may be lost. The network interface card (NIC) may not be able to keep up with the bandwidth. An advantage of polling is that polling is a small feature that is relatively easy to deploy. Implementing a general interrupt abstraction at the EFI layer (pre-OS, or boot environment, for example) is very difficult.